Hello @niemannd!
We are busy right now but we will come back to you as soon as possible! 🙂
Thanks for your PR!

Hi @niemannd !
I’m Amelie. I will take over from Sam, who changed team. First of all, thanks a lot for this PR! Besides the quality of the code than the rewrite of the Readme and Tests and for your clarity, this is nice from you, and I really appreciate it.
However, we want to keep all the SDK and this one too really simple for the users. So the goal is to keep the README and the usage like they are, even if it’s nice to have abstraction.
A default client still needs to be instantiated easily like this:

Client client = new Client(new Config("http://localhost:7700", "masterKey"));

even if we can let the possibility to customize it if we want.
And an index and document should still be accessible like this:

Index index = client.index("books");
index.addDocuments(documents);

Again thanks a lot for what you propose and your work. I understand your purpose not to have one uber class and create more accessibility. Still, this SDK is small and only contains few methods to bring too much complexity for the primary usage it offers.
I think we need to discuss a way to implement a solution that we could easily maintain, especially with simple usage.

A default client still needs to be instantiated easily like this even if we can let the possibility to customize it if we want

There are a few reasons i chose to not do that.

1. By circumventing the ClientBuilder you create a second "entrypoint" into the package. Generally i try to avoid that because sooner or later those entrypoints diverge and create additional problems.
   Also i think client = ClientBuilder.withConfig(new Config("http://localhost:7700", "masterKey")).build(); shouldn't be much of a problem?
2. A second entrypoint is not really user friendly. Software evolves. Telling people they have to change the way they create their client to use some advanced features is ....

And an index and document should still be accessible like this:
Index index = client.index("books");
index.addDocuments(documents);

I chose not to do that because this creates a number of problems.

1. Coming from an object oriented mindset, in this case you are working on an index-Object, not on the index itself. I would not asume that adding documents to the index-Object triggers any network operation.
2. This would merge the control layer of the code with the data layer. You have to expect that information about indexes are used in other parts of the application or even across applications. Maybe they are serialized/deserialized it. If at some point the underlying client gets dropped, your index will not be able do perform. Thats why, even for the index, i seperated data class from control class.
3. This way might work for the add-operation. It wouldn't work for get-operatons. you simply would not know how to deserialize the returned documents.

Hi @niemannd,
I hear what you're saying and I completely understand. It's not an implementation problem but that we have to make choices about what we want to offer to developers and what kind of product we want.
And it's part of the Meili philosophy that the SDK should be as developer-friendly as possible so we don't want to change the README and the usage.
If you still want to talk about it you can join me on slack.

And it's part of the Meili philosophy that the SDK should be as developer-friendly as possible so we don't want to change the README and the usage.

Honestly i don't see the developer-unfriendly part. Do you mean the Index class? A similar pattern is used in the meilisearch-go sdk. Do you mean the ClientBuilder? Again, a similar pattern is used by meilisearch-go and even Spring Data Elasticsearch

So please help me to understand whats the problem with changing the example in the readme of an SDK thats barely used at the moment. If there is a time to change it, its before the sdk is integrated into hundreds of backends.

Hi @niemannd,

A similar pattern is used in the meilisearch-go sdk. Do you mean the ClientBuilder? Again, a similar pattern is used by meilisearch-go and even Spring Data Elasticsearch

We actually do a refactor of the go SDK for the same reason. It is noted that it’s wasn’t clear for the user to pass the name of the index in the function like:
client.documents("books”); -> Seems to say I get the documents “book” not documents inside the index “book”.
For the ClientBuilder it’s really nice to have the possibility to customize it only if we still can have a default client which can be instantiated like this to:
Client client = new Client(new Config("http://localhost:7700", "masterKey”));
I would totally understand if you didn't want to resume your redesign. But if you don't, it would be very cool if you would take back these few points.